[4.x] Change from dot syntax to named-key access for scoped access in Alpine JS driver#8429
[4.x] Change from dot syntax to named-key access for scoped access in Alpine JS driver#8429martyf wants to merge 2 commits intostatamic:4.xfrom
Conversation
martyf
changed the title
|
I'm happy for a band-aid, but we should really prevent people from using dashes in field handles. |
|
I feel this is a slippery slope of an issue as it impacts a few areas: For the frontend:
For the backend:
And for a version update:
That last one is a little scary as it has potential to impact what users have already done (maybe they've written their own JS that relies on the handle - but if the upgrade changes the handle then that would break their JS). If nothing happens during the upgrade (i.e. nothing gets migrated) then the user needs to manually make changes which could be big (or small, or not an issue at all) - but also if they're not having issues with invalid characters, it's almost like they should be able to save without re-writing handles (what if they're fixing a typo elsewhere in the field/blueprint?). The speakingurl could be configured to not allow a dash (so that dashes in slugs are fine, but not Form blueprints): {
separator: "_",
custom: { '-' : '' }
}This would take Happy to try to help out where I can - but looking deeper is bigger than just a simple change as I think it has an impact across the whole platform. |
|
Hey Marty! Thanks for the PR and all the thought you put into this ❤️ One thing I found though is that this fix only works with scoped alpine data (as you said). This still errors when using I think the first step is to prevent dashes in field handles as Jason pointed out. We agree that some thought definitely needs to be put into the best way to tackle this for existing apps, but it's something that needs to be tackled at that level anyway, as dashes have caused problems in the new antlers parser, etc. as well. Closing this for now, but it's on our list for after Laracon 👍 |
3 participants
The Alpine Data Keys are accessed using a dot-syntax when using scoped data.
If a form's data is:
Then
data.nameworks as expected.However,
data.name_-_dashis not correct.The issue is that Statamic does allow the dash in a field handle (and in fact, allows very invalid handles to be saved, including spaces, special characters, etc).
While manually removing the invalid character manually works, it is not always that simple to instruct clients to make sure the handle - which is automatically generated for them - doesn't include a dash. While removing the dash is a simple step, it's also an extra human-responsible step that can go wrong.
A more permanent (and less human-responsible) solution should be implemented.
This PR changes the Alpine JS Driver's definition for data access to resolves the issue, and allows dashes in a field handle however only when using scoped data.
This would mean data is accessed using
data['name_-_dash"]which is correct.The benefit of this is that the Statamic CP Blueprint editor can continue working as it currently does but only with scoped data - and the accessing of data is corrected for this use case.
This is only a half fix though. If you do not use scoped data, you're out of luck.
There are two more permanent solutions:
Both of these bigger than just a simple fix and are a bit opinionated, but happy to chat further about how we've seen the Alpine JS driver used and work towards a more permanent fix.
Given this is only a half-fix, I appreciate it may not be accepted... but also is a bandaid fix to the issue too especially if using more complex forms and Alpine setups.